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ABSTRACT 

A Testbed for flight and ground systems compatible 
with the Consultative Committee for Space Data 
Systems (CCSDS) Recommendations has been 
developed at NASA’s Goddard Space Flight Center. 

The subsystems of an end-to-end CCSDS based data 
system are being developed. All return link CCSDS 
telemetry services (except Internet) and both versions 
of the CCSDS frame formats are being implemented. 
In key areas of uncertainty multiple design 
approaches are being carried out. In addition, key 
flight-qualifiable hardware components, such as 
Reed-Solomon encoders, are being developed to 
complement the testbed element development. 

The Testbed and its capabilities are described. The 
method of dissemination of the Testbed results are 
given, as are plans to make the Testbed capabilities 
available to outside users. Plans for the development 
of standardized conformance and compatibility tests 
are provided. 
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1. INTRODUCTION 

The National Aeronautics and Space Administration's 
(NASA's) Goddard Space Flight Center (GSFC) has 
instituted a significant testbed effort in the area of 
end-to-end data communications for space generated 
data. This program, the Advanced Orbiting Systems 
Testbed (AOST) Program, provides a bridge between 
development and widespread use of the Consultative 
Committee for Space Data Systems (CCSDS) 
Recommendations. Although named The Advanced 
Orbiting Systems Testbed, the Testbed in fact has the 
capability of creating and processing data compatible 
with both the Recommendation for Advanced 
Orbiting Systems (Reference 1) and of the 
Recommendation for Packet Telemetry (Reference 


2). NASA has been supporting the development of 
CCSDS Recommendations since 1983. The 
Recommendations, being used by most future NASA 
missions, offer the promise of significantly reducing 
mission life cycle costs by standardizing data 
handling interfaces and functions in both space and 
ground systems, and of significantly 
increasing the reliability of operations due to repeated 
use of well tested and established procedures. In 
addition, standardization gready enhances the ability 
of the various NASA space oriented subnetworks to 
operate with one another, and provides a solid basis 
for such interaction on an international basis where 
needed for international programs. Standardization 
allows the reuse of hardware and software, and makes 
it easier to support agency interoperation in national 
and international programs. 

The AOST Program systematically addresses current 
impediments to using the Recommendations. The 
multi-faceted approach to the AOST Program will 
reduce the remaining costs and risks associated with 
the implementation of the Recommendations within 
NASA. With one exception, it is not a prototyping 
program. It’s goal is the accumulation and 
dissemination of knowledge. 

2. THE AOS TESTBED PROGRAM 

The AOS Testbed Program has five main thrusts: 
developing and using the testbed itself, conducting a 
test program, performing directly related studies, 
developing critical flight-qualifiable components, and 
disseminating the knowledge gained in all the above. 

2.1 Development of the Testbed 

Development of the AOS Testbed draws upon the 
personnel and experience base of several different 
organizations with the GSFC. The flight-side 
equipment and the flight-qualifiable components are 
being developed by the Electrical Engineering 
Division. The front-end systems are being developed 
by the Data Systems Technology Division, as is one 
implementation of the Service Processors. Two other 
implementations of Service Processors are being 
developed by the Information Processing Division. 


143 



Services and Network Management is being 
developed by the MITRE Corporation. "Back-end" 
communications is being provided by the NASA 
Communications Division’s independent NASA Open 
Systems Interconnection Protocols (NOSIP) Testbed. 
A Production Data Processing (PDP) capability will 
be provided to the Testbed as software by the 
PACOR II Project. The entire Test Program, 
including test execution monitoring and test results 
analysis is the responsibility of CTA Incorporated, 
which is also the program support contractor, 
providing documentation, coordination, and other 
management functions. 

Development and use of the Testbed is divided into 
four phases or "Capabilities". Capability One 
provides the "unadorned" data handling functions for 
validation, architecture comparisons, and 
cost/performance evaluation. This capability is 
basically achieved. Capability Two sets these 
functions into an initial operations environment to 
identify performance degradation and to test interface 
definitions, requirements, and specifications . 
Capability Three completes the "rapid prototyping" 
into an operations environment and provides an initial 
set of standards conformance tests and systems 
compatibility tests. Capability Four completes the 
development of conformance and compatibility tests 
and provides the flight qualifiable components for 
flight project qualification. 

2.2 The Test Program 

The AOS Testbed test program is viewed as the 
primary means of obtaining the knowledge which is 
the objective of the Testbed. Testbed internal testing 
is performed to validate the achievement of each 
"Capability". Specific test periods (the majority of the 
Testbed development lifetime) are set aside for 
testing. The tests are formal and conform to a Master 
Test Plan and a Capability Test Plan; however, 
flexibility in schedule and sequence of testing is 
maintained in order to derive the greatest knowledge 
from the testing. Specific test program objectives are 
to: 

• define and validate internal and external 
data and system management interfaces for 
AOS systems 

• capture and disseminate knowledge gained 
in the implementation and testing of CCSDS 
Recommendations in an actual system 

• raise issues associated with the 
implementation and testing of CCSDS 
Recommendations and communicate these 
issues to the CCSDS 

® develop standard conformance tests and 
systems interface tests for use in acceptance 
testing by both flight and ground systems 


complying with the CCSDS 
Recommendations 

9 establish cost/performance curves for 
various configurations 

The AOS Testbed Test Program distinguishes five 
levels of testing complexity. These are: 

• Element Tests - performed by 
implementors to ascertain a unit is ready for 
integration into testbed 

• Compliance Tests - to determine that a unit 
does what it is supposed to do 

• Interface Tests - to determine that two 
units operate properly together 

• String Tests - to determine that three or 
more units operate properly together 

• End to End Tests - to determine that the 
entire system operates properly 

The Test Program has four types of tests. These tests 
may be conducted at any of the five test levels. The 
four types are: 

• Functional Tests - to determine that the 
system/subsystem does what it is supposed 
to do 

• Performance Tests - to determine that the 
system/subsystem performs at the speed or 
capacity or reliability, etc., that it is 
supposed to 

■ Regression Tests - to determine that the 
system/subsystem, after modification or 
upgrading, still performs properly 

• Research Testing - includes investigations 
of choke points, influence of architectures 
on performance, cost-performance curve 
measurements, etc. 

It is already clear that one of the most important 
products from the AOS Testbed will be the suite of 
tests that is being developed. The AOS Testbed is 
beginning a program for the development of standard 
test suites for "CCSDS Compatible" systems. The 
currently developed test suites will be restructured 
and enhanced to become standard test suites. It is 
planned these test suites will be made available to 
organizations that wish to do their own testing of 
existing or new systems. Both conformance and 
compatibility tests will be developed. Efforts are 
being made to accomplish this work in cooperation 
with the European Space Agency and possibly other 
international agencies. All results of this development 
effort will be provided to the CCSDS. 

In addition to the AOS Testbed's internal test 
program, the Jet Propulsion Laboratory (JPL), the 
European Space Agency (ESA), the Canadian Space 
Agency (CSA), and the National Space Development 
Agency of Japan (NASDA) have expressed interest in 
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cooperative testing. A specific plan for testing with 
ESA is in its final preparation stage. 

2.3 Related Studies 

By far the most significant study effort being 
supported by the AOS Testbed is its participation in 
the ad hoc inter-Center Space Operations Service 
Infrastructure (SOSI) working group. Most of the 
members of this group are also members of CCSDS 
Panel 3. The SOSI group is developing a top-down, 
end-to-end graphical model that can be used to: 

* Develop service concepts 

« Develop operations concept 

• Identify cross support points, protocols, 
and formats 

* Discuss cross support issues and interfaces 

• Be a basis for CCSDS Panel 3 work 

The CCSDS Packet Telemetry, Telecommand, and 
AOS protocols are tuned to operate across the space 
link, terminating in a ground station. The CCSDS 
space link protocols conserve bandwidth (and allow 
high speed data processing) by using managed 
information instead of in-band signaling and by 
minimizing redundancy. The Ground System must 
extend the services provided by these space link 
protocols to user application processes. Usually the 
user applications are in a Ground-based End System 
(GES) that is provided data from several distant 
Ground-based Spacecraft Access (GSA) systems over 
commercial or private data networks. The GSA is an 
intermediary between the space link and various end 
systems on the ground. GSAs typically provide 
services to many missions. The scheduling, 
management, and reporting necessary to allow 
multiple missions to receive services from multiple 
GSAs - efficiently and correctly - is a key aspect 
which the SOSI model is intended to illustrate. A key 
function of the GSA is to apply annotation 
information before the data unit leaves the GSA. The 
annotation information is of two types: 

•SDU Information which is specific to each 
sublayer of the service: 

-information not known prior to 
ground receipt (e.g., loss of sync; 
Reed-Solomon Corrections; 
Sequence Discontinuities, ground 
receipt time) 

-information carried in one sublayer 
but needed in another sublayer (e.g. 
Spacecraft ID) 

-known prior to ground receipt but 
lost if the service were to be 
extended beyond the RF terminal . 
•Managed information: distributed systems 
will be easier and cheaper to operate if 
information which is managed over the 


space link subnet due to bandwidth 
limitations, is signaled over the ground 
system. 

In addition, an agency implementing a GSA may 
wish to attach agency specific annotation information 
for purposes of accounting and fault isolation (e.g., 
system IDs). 

The SOSI model and related concepts are being 
developed in cooperation with the AOS Testbed. 

Both architectural issues and data format 
development are worked between the "top-down" 
approach of the SOSI and the "bottom-up” 
experimentation within the Testbed. A more detailed 
discussion of the SOSI work may be found in 
Reference 3. 

A key element in this cooperative work is the content 
and format of the annotation information. The 
annotation information is applied to each data unit to 
be delivered by the GSA. The annotation mechanism 
as so far developed by the AOS Testbed, is called a 
Space Operations Service Data Unit (SOSDU) header 
(when the header is added to the data unit, the 
combination is called a SOSDU). The SOSDU header 
currently contains a generalized label, a SOSDU label 
which is the same for all SOSDUs, a set of Service 
specific parameters which are different for each of 
the Services, and possibly optional agency and/or 
network unique fields. The SOSDU header is a 
relatively early stage of development and is expected 
to change significantly over the next several months. 
A major revision to the format is expected to be 
completed within the next month. 

2.4 Flight-Qualifiable Components 

The objective of this part of the AOS Testbed 
Program is to generate key products to promote flight 
project use of CCSDS Recommendations. These 
products were planned to include flight qualifiable 
coding components, flight qualifiable frame level 
components, and flight qualifiable packet 
generators/buffers. A good foundry run has already 
been achieved of a single chip, high speed Reed- 
Solomon Encoder. The chips will be made available 
through the University of New Mexico. 
Unfortunately, the current budget situation has 
required a halt in the funding of this activity. It is 
hoped that some FY93 funds can be found to 
continue the work at a lower level of activity, or that 
it can be re-started in FY94. 

2.5 Dissemination of Knowledge Gained 

The primary vehicle for the dissemination of the 
knowledge gained through the various activities of 
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the AOS Testbed is the annual "Workshop for 
CCSDS Implementors". The first of these was held 
on November fourth and fifth of this year at the 
Goddard Space Flight Center, and was very 
successful. Over 300 persons attended, representing 
44 companies, 2 universities, 4 NASA Centers, 

NASA Headquarters, and the Department of Defense. 
The attendance was far in excess of our expectations, 
demonstrating a very broad interest in CCSDS 
implementations. (A reason for this wide-spread 
interest can be seen in Table 1, Spacecraft/CCSDS 
Compatibility.) The attendance was so large that we 
found it impractical to actually have a "workshop", 
and it was in fact a seminar. We will change the 
format for the next workshop, at least part of the time 
breaking up into interest groups, thereby providing a 
true workshop environment. 

3. AOS TESTBED ARCHITECTURE 

There are two major architectural drivers considered 
within the AOS Testbed Program. First is the 
distribution of functions due to network and facility 
drivers. Second is the allocation of functions to 
subsystems within a major "infrastructure" 
facility. The first is being addressed by the Space 
Operations Service Infrastructure (SOSI) group (see 
above). So far, the two drivers seem to lead to a 
highly compatible allocation of functions. The testbed 
architecture was selected to expose potential cross 
support (inter-network) points, provide easy access to 
inputs and outputs of major functional blocks, and to 
allow easy and standardized (serial) interconnection 
among the elements. The testbed elements, shown in 
Figure 1, represent all of the subsystems of the return 
side of an end-to-end data system (forward link 
capability is not presently included or funded). The 
rate performance target for the ground side is 20 
mbps peak, and for the flight side, 80 mbps peak. 
Simulators are used for the end users systems, both 
onboard and on the ground. 

A more detailed drawing of the Flight Elements of 
the Testbed is shown in Figure 2. The digital video 
equipment string is not yet completed, but is expected 
to be added in late spring of 1993. A detailed drawing 
of the ground side configuration is given in Figure 3. 
It is in this Figure that the major architectural features 
are discernible. The Local Area Networks (LANs) of 
the Testbed may, in real-world implementations, be 
Wide Area Networks (WANs). The same is true of 
the second Testbed LAN. The multiple 
implementations of the Services Processors allow for 
experimentation in both the geographical distribution 
of Services Processors and in the maximization of 
resources utilization in a heterogeneous multi-user 
ground facility. 


Results from testing and study in the AOS Testbed 
may be found in Reference 4. 
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TABLE 1 SPACECRAFT/CCSDS COMPATIBILITY 
SPACECRAFT LAUNCH FRAME R-S CODING PACKETS PKT TIME CODE FWD LNK 


EUVE 

92 

NO 

NO R-S 

YES 



SAMPEX 

92 

YES 

CCSDS CONV 

YES 

YES 

YES 

FAST 

94 

YES 

CCSDS CONV 

YES 

YES 

YES 

SWAS 

95 

YES 

S 

YES 

YES 

YES 

SOHO 

95 

YES 

YES 

YES 

YES 

YES 

XTE 

96 

YES 

YES 

YES 

YES 

YES 

TRMM 

97 

YES 

YES 

YES 

YES 

YES 

ACE 

97 

YES 

YES 

YES 

S 

S 

SMEX4 

96 

YES 

S 

YES 

YES 

YES 

SMEX5 

97 

YES 

S 

YES 

YES 

YES 

SMEX6 

98 

YES 

S 

YES 

YES 

YES 

EOS-AM 

98 

YES 

YES 

YES 

YES 

YES 

EOS-PM 

99 

YES 

YES 

YES 

YES 

YES 

SSFP 

96 

YES 

YES 

YES 

S 

YES 

MARS OBSRVR 

92 

YES 

YES 

YES 

YES 

NO 

CASSINI 

97 

YES 

YES 

YES 

YES 

YES 


S = UNDER STUDY 


FIGURE 1 AOS TESTBED ELEMENTS 
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FIGURE 3 AOS TESTBED GROUND SIDE CONFIGURATION 


EXTERNAL 
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